I like the idea of having something like this. It would be nice to have it more explicit that you might have public and encrypted data coexist in a list. I'm not sure why we need n and u tags in addition to d though. Didn't you start by defining a new range? It seems to me we could just pick a regular event kind (<10000), use d as the name, and a instead of u to refer to all events in the list.

It would be nice to have it more explicit that you might have public and encrypted data coexist in a list.

Added "Public and encrypted data can coexist in unbounded list events similar to NIP-51 lists." Thanks

Didn't you start by defining a new range? It seems to me we could just pick a regular event kind (<10000), use d as the name, and a instead of u to refer to all events in the list.

I realized we didn't need a new range; just reserving the n tag to mark an event as being part of a list would be enough. Adding/removing n tags from an event is needed, so most times the event needs to be replaceable.

Even though this solves follow lists being huge, it doesn't solve follow notifications. I wish it did.

It kinda solves it. If pubkeyA makes a REQ for kind:30382 and d:pubkeyA, pubkeyA will receive all modifications made by everybody else's follow (and other lists) with pubkeyA. You can show a notification like this:

pubkeyB has changed your status to include the lists: follow, friend and idiot.

It's broader than just follow/unfollow.

It kinda solves it.

Yeah the client would need to track n tag changes cause although the filter { kinds: [30382], #d: ["<user>"], #n: ["follow"], since: <last-time-checked> } would include events that were updated since the timestamp, the update could have been on another n tag.

Tracking isn't that great, cause one may have thousands/millions followers.

Ideas:
A) kind:30382 n tags could include a timestamp to use client side like ["n", "follow", "<updated_at>"]

B) Or we add uppercase N tag to the kind:30382 with just n tag values that were added/removed at last event update. Then you do { ..., #N: ["follow"] }

C) Or we could use an auxiliary "Set Change Notification" event just with the n tag changes?

I like the local solution. If it is the first start, the notification can just be more generic (people don't care about new follows in the first start). Once the client has received some events, it can then display the differences between them on updates.

Yes, it just doesn't make the problem much easier.

I still like this event sets idea a lot, though. i'm working on implementing it in Ditto.

Why does the target event's pubkey need to be in the d tag for kind 30383 events?

@arthurfranca Should this be unmarked as a draft?

I am just realizing that with this, we are just swapping an event with thousands of keys (e.g. the contact list) to an event with thousands of list names (e.g. new 30382).

Different race conditions, but race conditions might still be a problem if lists become a common feature of Nostr clients.

Regardless, this is a good evolution.

@vitorpamplona It seems very improbable that a single user would add another single user to 1000+ lists. Even power users will have hundreds at most, while they will follow thousands of users. So the scale is very different, and it minimizes the potential damage of race conditions to your relationship with individual users instead of your entire list.

Btw, I implemented event sets in Ditto. The Ditto nsec tags pubkeys with ["n", "admin"], ["n", "suspended"], and ["n", "suggested"] for user roles, globally suggested users, and moderation (etc.)

It also generates event sets for reports and some other things, which it tags with ["n", "open"] and ["n", "closed"] so the server can manage their state and filter by it.

I will soon be implementing private user notes and user-recommended follows with this. I think it's very needed, and the n tag is a great idea.

I replaced the custom kind 30361 event I was using in Ditto with kind 30382.

I think this PR is ready. Just would like to make it clear that although this PR has all the necessary steps to migrate from NIP-51 lists, it does not aim to make clients migrate from NIP-51. Though it opens the possibility to experiment migrating less "important" ones like using "mute" event sets instead of "mute" NIP-51 lists. Also, it opens the door to using events sets for new use cases where one would otherwise spec a new NIP-51 list.

IMO this not much more than a clever hack, and not a fundamental solution of the problem of follow list race conditions. I don't really see myself adopting this except to be interoperable with other features I want to support. But migrating things to it is just not going to happen, for me or many other devs.

To that point, it's a very bad idea to add some of the "standard" event sets listed. What is the semantic difference between a follow list and a follow set? Which is canonical? Is the newer one better? People are going to see this NIP and think it replaces kind 3 follow lists, and start writing only sets. Or they'll attempt to implement complicated reconciliation logic and fail. I think if people start to use any of the bookmark, follow, mute or pin sets, which are already defined by NIP 51, we're going to have fragmentation of implementations, and it will greatly damage interoperability.

One can't be against event sets while in favor of #1322 cause #1322 uses event sets. Simple logic.

In fact, from the above comment I only see you are against some of the event set names. I will remove bookmark, follow, mute and pin.

Indeed. I was thinking, the only thing Event Sets competes against (as far as "do things one way") is Lists... in concept.

But it's the specific names/list kinds that need to not compete. The concepts should be able to coexist.

Sets and Lists are different things. There is some intersection, but sets do not replace Lists at all times.

One can't be against event sets while in favor of #1322 cause #1322 uses event sets. Simple logic.

I'm against both. I just recognize that I have no power to prevent sets being used. Yes, sets are different from lists, but not different enough IMO to complicate the protocol with them (especially when we also have labels).

Removed the part that is now available at #1322 (and also extended at #761).

The PR is just defining event sets and some basic event set names.

I'm going to stop pushing NIPs for a while after I felt that I had to deface this PR to fit whatever requirements to move this forward. Sometimes there is no guidance to improve a PR, just unconstructive reviews that show up after months.

More info at https://nostr.at/nevent1qy88wumn8ghj7mn0wvhxcmmv9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy2hwumn8ghj7un9d3shjtnwdaehgu3wvfnj7qgswaehxw309ahx7um5wghx6mmd9uq32amnwvaz7tmwdaehgu3wdau8gu3wv3jhvtcpzpmhxue69uhkumewwd68ytnrwghsz8nhwden5te0dehhxarj94c82c3wwajkcmr0wfjx2u3wdejhgtcpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp0qqspk2fwtnyr32ava9skgm27f8l5plveswxvk28dhd86tyxpjkccg9cqnvj9j